#Claude Code 重塑软件开发流程

#从瀑布模型到 AI 工作流

#传统软件工程流程

经典的瀑布开发模型包含以下阶段：

flowchart LR
    A[需求分析] --> B[系统设计]
    B --> C[详细设计]
    C --> D[编码实现]
    D --> E[单元测试]
    E --> F[集成测试]
    F --> G[系统测试]
    G --> H[上线部署]

每个阶段都有明确的产出物：

#业界的解决思路

传统流程虽然严谨，但各阶段割裂明显，文档与代码易脱节，且需要大量人工协调。 针对文档与代码脱节的问题，目前有两种主流的 AI 工作流方案：

GitHub Spec Kit — 规格驱动开发（Spec-Driven）

GitHub 官方推出的 Spec Kit 把规格文档变成可执行的制品，让 AI 直接从规格生成计划和代码。流程分 6 步：constitution→specify→clarify→plan→tasks→implement。核心思路是「自顶向下」——先写完整规格，再逐步细化到代码。适合从零开始的新项目，或需要跨团队对齐需求的场景。

Superpowers — 技能驱动开发（Skill-Driven）

社区项目 Superpowers 走的是「渐进式」路线——不要求预先写完整规格，而是通过 brainstorming 在对话中逐步收敛需求，技能会主动读项目代码，基于已有实现提出针对性问题。流程分 4 步：brainstorming→writing-plans→executing-plans→debugging。适合在已有项目上做功能迭代。

两者本质上解决的是同一个问题：把传统软件工程的文档流程融入 AI 编程过程。区别在于，Spec Kit 要求先把规格文档写好落盘，再交给 AI 执行；而 Superpowers 的文档不需要落盘，而是在对话中实时生成、实时交给 AI 理解——因为编码工作本身就是由 AI 完成的，文档的消费者就是 AI，没必要走传统的文档归档流程。

我们推荐使用 Superpowers 这类技能驱动的方案。原因很简单：在 AI 编程场景下，文档的目的不再是给人看，而是给 AI 提供上下文。brainstorming 产出的设计文档直接作为 writing-plans 的输入，plans 产出的任务列表直接作为 executing-plans 的输入，整个链路在对话中闭环，不存在文档与代码脱节的问题。本文以 Superpowers 为例展开。

#AI 编程的常见问题

AI 编程助手（包括 Claude Code）在没有约束的情况下，容易出现以下问题：

模糊需求，跳过规划，直接写代码

• 用户：「给报销模块添加审批流程，参考请假模块」
• AI：立即照搬请假模块的单级审批逻辑，未考虑金额分级、多级审批、驳回重提等差异
• 结果：需求理解偏差，后续大量返工

缺少分解，一次性实现

• 将复杂功能作为单一任务执行
• 中途出错难以定位问题点
• 无法分阶段验证正确性

#Superpowers 如何对应传统流程

Superpowers 将瀑布模型的每个阶段映射为 AI 可执行的技能，用强制性工作流替代人工协调：

flowchart LR
    A[模糊需求] --> B[brainstorming<br/>需求分析]
    B --> C[设计文档]
    C --> D[writing-plans<br/>任务规划]
    D --> E[实现计划]
    E --> F[executing-plans<br/>分批执行]
    F --> G[代码实现]
    F -.遇到问题.-> H[debugging<br/>系统排查]
    H -.修复后.-> F
    G --> I[功能完成]

#Superpowers 技能库

#安装

npx skills add https://github.com/obra/superpowers --skill brainstorming

npx skills add https://github.com/obra/superpowers --skill writing-plans

npx skills add https://github.com/obra/superpowers --skill executing-plans

npx skills add https://github.com/obra/superpowers --skill systematic-debugging

#核心技能

#各阶段输入输出

#实战：报销审批流程

以 PIGX 项目的 OA 模块为例，演示从模糊需求到清晰设计的完整流程。

#为什么选「报销审批流程」

项目中请假模块已有完整审批流程，但报销模块只有基础 CRUD，缺少审批——这是实际存在的功能缺口。选择这个场景有三个原因：

1. 真实痛点 — 报销模块缺少审批是项目里实际存在的功能缺口
2. 有参照物 — 请假审批流程可以作为对比，brainstorming 不是凭空设计，而是结合已有代码做决策
3. 决策点丰富 — 报销审批比请假复杂（涉及金额分级、多级审批、财务确认等），能充分展示 brainstorming 的问答价值

#阶段一：Brainstorming

用户输入模糊需求后，brainstorming 技能自动介入，通过一系列问题把需求变成清晰设计。

触发示例：

给报销模块添加审批流程，参考请假模块的做法。

这句话故意模糊——「参考请假模块」到底参考到什么程度？报销有哪些特殊性？这些都没说清楚。

问答过程：

Claude 会逐个提问，每次只问一个问题。brainstorming 会先读现有代码，发现 LeaveStatusEnum、BmpOaLeaveAudit、RabbitMQ 配置等，基于项目实际情况提问：

轮次 1:
Claude: 报销审批是否需要按金额分级？比如 1000 以下主管审批，1000 以上需要总监审批？
  1. 是，按金额分级审批
  2. 否，统一单级审批

→ 请假模块是单级审批，报销通常需要分级，这是关键差异

轮次 2:
Claude: 审批状态是复用 LeaveStatusEnum 还是新建一个 ReimburseStatusEnum？
  1. 复用 LeaveStatusEnum
  2. 新建 ReimburseStatusEnum（推荐，报销状态更多）

→ 项目里已有状态枚举，需要决定是复用还是独立

轮次 3:
Claude: 报销审批驳回后，是否允许修改金额后重新提交？
  1. 允许修改后重新提交
  2. 驳回即终止，需重新发起

→ 请假驳回后可以撤回重提，但报销涉及金额变更，逻辑不同

轮次 4:
Claude: 审批通过后是否需要触发 MQ 消息通知？项目已集成 RabbitMQ。
  1. 是，通过 RabbitMQ 发送通知
  2. 否，暂不需要消息通知

→ 项目已有 MQ 基础设施，brainstorming 会发现这个可复用的能力

轮次 5:
Claude: 审批记录是新建 BmpOaReimburseAudit 表，还是做一个通用审批记录表？
  1. 新建专用 BmpOaReimburseAudit 表
  2. 做通用审批记录表，请假和报销共用

→ 架构决策——当前请假有专用审批表，是否要抽象

产出文档示例：

报销审批流程设计

1. 审批规则
   - 金额 <= 1000：主管一级审批
   - 金额 > 1000：主管审批 + 总监审批

2. 状态流转
   - 新建 ReimburseStatusEnum（草稿→待审批→主管已批→已通过/已驳回→已撤回）

3. 驳回处理
   - 允许修改金额和明细后重新提交

4. 消息通知
   - 审批通过/驳回时通过 RabbitMQ 发送通知

5. 数据存储
   - 新建 bmp_oa_reimburse_audit 审批记录表

#阶段二：Writing Plans

设计文档确认后，用户表示"准备开始实现"，Claude 调用 writing-plans 技能，将设计拆分为可执行的任务列表。

任务列表示例：

任务 1: 创建 ReimburseStatusEnum 审批状态枚举
任务 2: 创建 BmpOaReimburseAudit 审批记录实体和 Mapper
任务 3: 实现审批 Service（含金额分级逻辑）
任务 4: 编写审批 Controller 接口（提交、审批、驳回、撤回）
任务 5: 集成 RabbitMQ 消息通知
任务 6: 添加单元测试

依赖关系：

flowchart LR
    T1[任务1: 状态枚举] --> T3[任务3: Service]
    T2[任务2: 实体/Mapper] --> T3
    T3 --> T4[任务4: Controller]
    T3 --> T5[任务5: MQ通知]
    T4 --> T6[任务6: 测试]
    T5 --> T6

#阶段三：Executing Plans

计划确认后，Claude 调用 executing-plans 技能，按批次推进任务。

批次执行机制：

不是一次性执行所有任务，而是分批进行。每批完成后暂停，等待用户确认后继续。

执行过程示例：

正在执行: 任务 3 - 实现审批 Service（含金额分级逻辑）

- 创建 BmpOaReimburseAuditService 接口
- 实现 submitForApproval 方法（提交审批）
- 实现 approve 方法（含金额分级判断：<=1000 主管直接通过，>1000 流转至总监）
- 实现 reject 方法（驳回，允许修改后重提）
- 实现 withdraw 方法（撤回）

任务完成，继续下一个任务？[Y/n]

验证机制：

每个任务完成后自动检查：

• 代码是否编译通过
• 是否符合设计文档约定
• 测试任务执行后是否通过

#阶段四：Debugging

执行过程中遇到错误时，debugging 技能介入进行系统化排查。

场景示例：

报销提交审批后，金额 > 1000 的单据没有流转到总监，直接变成了「已通过」。

排查流程：

第一步: 收集信息
- 查看审批 Service 日志
- 检查提交的报销金额
- 确认 ReimburseStatusEnum 状态流转

第二步: 形成假设
- 假设 1: 金额比较逻辑有误（使用了 == 而非 compareTo）
- 假设 2: 分级审批条件判断分支未覆盖
- 假设 3: 主管审批后未正确触发总监审批流程

第三步: 逐个验证
- 打印审批方法入参: amount = 1500, 但走了 <= 1000 的分支
- 定位原因: BigDecimal 使用了 == 比较而非 compareTo

第四步: 修复并验证
- 改用 compareTo 比较金额
- 重新提交 1500 元报销单，确认流转到总监审批